PACKET FORMATS OF AX.25 LEVEL 3 PROTOCOL 


Terry Fox, WB4JFI 

President, 

1819 Anderson Rd. 
Falls Church, VA 22043 


Description 


This paper is part two of a series of papers 
that. describe The Network Sublayer portion of an 
AX.25 data communications system. 


The purpose of this paper is to describe the 
formats of the various types of packets used to 
establish, maintain, and tear down a connection 
between a DTE and a DCE, along with the packets 
necessary to control the data flow along that 
connection while it is operational. 


This paper was generated by taking the CCITT 
X.25 document and adding or deleting information 
pertaining to amateur radio data networking. 


This is a first draft, corrections and 
ammendments will be forthcoming. Follow the AMRAD 
Newsletter (see information in the first paper of 
this series) for further information. 


6 Packet Formats 
6.1 General 


The possible extension of packet formats by 

the addtion of new fields is a subject for further 
study. In general any additional field would: 
a) only be provided as an addition following all 
previously defined fields, not as an 
insertion between any prevrously defined 
fields; 


be transmitted to a DTE only when either the 
DCE has been informed that the DTE is able to 
interpret this field and act accordingly, or 
when the DTE can ignore the field without 
adversely affecting the operation of the 
DTE/DCE interface; 


b) 


c) not contain any information pertaining to a 
user facility to which the DTE has not 
subscribed, unless the DTE can ignore the 
facility without adversely affecting the 


operation of the DTE/DCE interface. 


Bits of an octet are numbered 8 to 1 where 
bit 1 is the low order bit and is transmitted 
first Octets of a packet are consecutively 
ee starting at 1 and are transmitted in this 
order. 


6.1.1 


General format identifier 


The general format identifier (GFI) field is 
a four bit binary coded field which is used to 
indicate the general format of the rest of the 
packet header. The_GFI is located in bit 
ositions 8, 7,6,and 50f octet 1, with bit 5 
eing the tow order bit (see Table 7/AX.25). 
Values for the GFI not specified in Table 7/AX.25 
are reserved for future use. 


Bit 8 of the GFI is used for the Qualifier 
bit (Q bit) in data packets, and is set to 0 in 
all other packets. 


Bit 7 of the GFI is used for delivery 
confirmation (D bit) in data packets. It is set 
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to 1 in call set-up packets, and is set toOin 


all other non-data packets. 


Bits 6 and 5 are encoded O and 1 
reaper e ee indicating that all sequence 
numbering will be done modulo 8. The encoding of 
bits 6 and_5 to_1 and 0 is reserved for future 
use. Bit and JYencodings of both zero or both 
one are not allowed under this recommendation. 


General Format Identifier (GFI) ! Octet 1! 


bits ! 
4 18765 i 
! Call set-up packets !o0101! 


i Clearing, flow control, ! ! 
. interrupt, reset, restart, 1oool1! 
! and diagnostic packets ! ! 


Jewenencnnne= a he | 


Data packets 1xxol! 


Where: 


a bit marked X may be either a 0 or al as 
indicated elsewhere in the text. 


Table 7/AXK.25 
General Format Identifier 
6.1 


“2 Logical channel group number 


The Logical channel group number (LCGN) is in 
all packets except for restart or diagnostic 
packets. It is binary encoded, and resides in bit 
pogttions 4, 3,2, and 1 of octet 1, with bit 1 

eing the low order bit. For each logical 
channel, this number has local significance at the 
DTE/DCE interface. 


In restart and diagnostic packets the logical 
channel group number is set to all zeros. 


6.1.3 


The logical channel number (LCN) is in all 
packets except for restart or GT AEnOSELE packet!. 
It is biimary encoded. and resides in all bit 
positions Ofoctet 2, 'with bit 1 being the low 
order bit. For each logical channel, the LCN has 
local significance at the DTE/DCE interface. 


Logical channel number 


In restart and diagnostic packets the logical 
channel number is set to all zeros. 


6.1.4 


Each packet type_will be identified by the 
encoding of octet of the packet. This 
identifier takes all bit positions, and_is encoded 
as shown in Table 8/AX.25 (Table 8/AX.25 is at the 
end of this paren) Packet Types identifiers * bee 
than those shown in Table 8/AX.25 are reserved. 


6.2 Call. set-up and clearing packets 


6.2.1 Call request and incoming call packets 


Figure 1/AX.25 illustrates the format of call 
request and incoming call packets. 


Packet type identifier 


Bit Position 
8 7 6 5 3 2 1 
! General Format ! Logical Channel ! 
Identifier (GFI) ! Grou nome 
00 1 0 1) Rice 
Logical Channel Number os 


| 
! 
! 
iedenswenccosdacecume ts) coe a 5% severe 
t 
! 
t 


HmHao 
tS 


! Calling DTE ! Called DTE ! 
bs Address Length a Address Length ! 
DIE Addresses j 
(see Note, dee ate ‘ 
0: 0. <O- 20 ! 


! mmr mwm eee eeeeeee sees aeuneen seca ssaereseeee 


0 0! Facility Length | 


Call User Data 
(see Notes 2 and 3) 


ee ee 


The figure is drawn assuming the total 
amount of address information is not an 
integral number of octets. Each address 
sub-field oo pore ee of variable 
length, any padding necessary is added at 
the end, and will consist of zeros. 


Bits 8and 7of the first octet of the 
call user data field ey. have particluar 
significance (see 6.2.1 


Note 2. 


Note 3. Maximum length of the call user data 


field is 16 octets. 


Figure 1/AX.25 
Call request and incoming packet format 


6:21 General format identifier 

_ Bit 8(Q bit) shall be set to 0, bit 7 (D 
bit) shall be set to 1, and bits 6 and 5 should be 
set to 0 and 1 respectively. 
Ge 2a? Address lengths field 


Octet 4 consists of field length indicators 
for the called and calling DTE address fields. 


Bits 4, 8, 2, and 1 indicate the called DTE 
address leng:h in semi-octets (nibbles)). Bits 8, 
7; » and indicate the calling DTE address 


length in nibbles. Each address length indicator 
is encoded in binary, with bits 1 and 5 being the 
low order bits of their respective indicators. 


6.20 Le3 Address field 


Octet 5 and the follower: octets (up to 32 
octets) consist of the called DTE address, 
followed by the calling DTE address. These 


addresses are encoded as described in Annex F. 
62 ded 


The octet. following the DTE address fields 
contains the facility length field. This octet 
has bits 8and 7 unassigned, and both are set to 
0. Bits 6, 5, 4, 3, 2, and 1 contain the facility 
length information. This information is binary 
coded, with bit 1 being the low order bit. 


6.20109 


The facility field is present only when the 
DTE is using an optional user facility requiring 
some indication in the call request and incoming 
call packets. 


Facility length field 


Facility field 


The coding of the facility field is described 
in section 7% 


The facility field must contain an_integral 
number of octets. The actual maximum length of 
this field depends on the facilities which are 
offered by the packet switch and network. The 
maximum number must not exceed 63 octets at any 
time. 
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6.2.1.6 


A call user data field may be present 
following the facilities field. This field may be 
up to 16 octets long, and must contain an integral 
number of octets. 


Call user data field 


f a call user data field is present, the use 
and format of this field are determined by bits 8 
and 7 of the first octet of this field in 
accordance with the following: 


f bits 8and 7are 00, 
user data field is 
identification in accordance 
Recommendations (such as AX.29). 


a portion of the call 
used for protocol 
with other 


f bits 8 and 7 are set to 01, a portion of 
the call user data field may be used for 
protocol identification in accordance with 
specifications of networks. 


If bits 8 and 7 are 10, a portion of the call 
user data field may beused for protocol 
identification in accordance with 
specifications of international user bodies. 


If bits 8 and 7 are set to 11, no constraints 
are placed on the use by the DTE of the 
remainder of the call user data field. 


Users are cautioned that if bits 8 and 7 have 
a value other than _11, a protocol may be 
identified that is implemented within the network. 


When a virtual call is established between 
two packet mode DTEs, the network does not act on 
any part of the call user data field. 


6.2.2 Call accepted and call connected packets 


Figure 2/AX.25 illustrates the format of call 
accepted and call connected packets. 


Bit Position 
5 4 3 


General Format Logical Channel ! 


! Identifier (GFI) ! 


Group Number ! 
0 ! 0 1 0 1 I (LCGN) } 
Cc {mmm m meme meme ewer ne= -~_e es = wm wa ww oo 1 
: 2nd Logical Channel Number (LCN) 
T Packet Type “Tdenti fier | 
3! 0 0 0 60 1 0 eee : 
1 sltina. DTE Called DTE t 
4 ! Address Length Address Length ; 
Vv DTE Addresses 
A (see Note 1) 
R See ee meen emmoensacoe 
| 0 0 0 0 : 
0 0! Facility Length 
ee 
A! Facilities ! 
R (see Note 2) ' 
Note 1. The figure is drawn assuming the total 
amount of address information is not an 
integral number of octets. Each address 
sub-field eae areas of variable 
length, any padding necessary is added at 
the end, and will consist of zeros. 
Note 2. 


The facility field is not mandatory in 
call accepted packet (see 6.2.2). 


Figure 2/AX.25 
Call accepted and call connected packet format 


62s Zeek General format identifier 


Bit 8(Q bit) shall be set_to 0, bit 7 (D 
bit) shall be set to 1, and bits 6 and 5 should be 
set to 0 and 1 respectively. 


Address lengths field 
Octet 4 consists of field length indicators 


for the called and calling DTE address fields. 
Bits 4, 3, 2, and 1 indicate the called DTE 


sh in semi-octets (nibbles). Bits 8, 

indicate the calling DTE address 
length in nibbles. Each address length indicator 
is encoded in binary, with bits 1 and 5 being the 
low order bits of their respective indicators. 


6.24293. Address field 


Octet 5 and the follows ne octets (up to 32 
octets) consist of the called DTE address, 
followed by the calling DTE address. These 
addresses are encoded as described in Annex F. 


6.2.2.4 


The octet. following the DTE address fields 
contains the facility length field. This octet 
has bits 8 and 7 unassigned, and both are set to 
QO. Bits 6 5, 4, 3, 2, and 1 contain the facility 
length information. This information is binary 
coded, with bit 1 being the low order bit. 


address len 
7; » and 


Facility length field 


The use of the facility length field in call 
pada ae packets is mandatory. It should be set 
to all zeros if there is no facility field. 


6.2.2.5 


The facility field_is present only when the 
DTE is using an optional user facility requis 
some indication in the call accepted and cal 
connected packets. 


Facility field 


The coding of the facility field is described 
in section 7 


The facility field must contain an integral 
number of octets. The actual maximum length of 
this field depends on the facilities which are 
offered by the packet switch and network. The 
maximum number must not exceed 63 octets at any 
time. 


6532.3 Clear request and clear indication 


packets 


Figure 3/AX.25 shows the format for clear 
request and clear indication packets. 


Logical Channel ! 
Group Number ! 


! General voenee, | 
! Identifier (GFI) 0! 
! ~~ YD YD ! 


HPYWQ 0 


2 !____Logical Channel Number (LCN) | 
! ies Type 

3 esc cOu ccc Olen ol 1 ee dentifier--.Lle.-! 
i 0) (0) t 

4! Clearing Cause ; 
I Diagnostic Code { 


Figure 3/AK.25._ 
Clear request and clear indication packet format 


6.2.3.1 


Octet 4 is the clearing cause field, which 
contains the reason for the clearing of the call. 


Clearing cause field 


In clear request 
field should be set 
following values: 


Doeee the clearing cause 
y the DTE to one of the 


bit: 87654321 

valuel: 00000000 

value2: 1XXXXXXX 
where X may be either 0 or 1 


The DCE will prevent values other than those 
specified above in the clearing cause field from 
reaching the other end of the call by considering 
the clear request as an error and following the 
procedure described in Annex C. 


The coding of the clearing cause field in 


clear indication packets is given in Table 
9/AX.25 (Table 9/AX.25 is at the end of this 
paper). 


3.32 


62d d, Diagnostic code 


Octet 5 is the diagnostic code which contains 
additional information on the reason for the 
clearing of the call. 

In a clear request packet, the diagnostic 
code is not mandatory. 


In a clear indication packet, if the clearing 
cause field indicates "DTE originated", the 
diagnostic code is passed unchanged from the 
clearing DTE. If the clearing DTE has not 
provided a diagnostic code in its clear re eee 
packet, then the bits of the diagnostic cae ‘ib 
the resulting clear indication packet will all be 


zero. 


When a clear indication packet results from a 
restart request packet, the value of the 
diagnostic code will be that specified in the 
restart request packet, or all zeros in the case 
where no diagnostic code has been specified in 
restart request. 


When the clearing cause field does not 
indicate "DTE originated , the diagnostic code in 
a clear indication packet is network generated. 
Annex E lists the coding. for network generated 
diagnostics. The bits of the diagnostic code are 
all set to zero when no specified additional 
information for the clearing is supplied. 


The contents of the diagnostic code field do 
not alter the meaning of the cause field.. A DTE 
is not required to undertake any action on the 
contents of the diagnostic code. field. 
Unspecified code combinations in the diagnostic 
code field shall not cause the DTE to refuse the 
cause field. 


6.2.4 


Figure 4/AX.25 shows the format of the DTE 
and DCE clear indication packets. 


DTE and DCE clear confirmation packets 


Bit 
wun SG. .2y y Position 3.12.1, 

1 ! GeneralGFoupat ! LNgintedr Channel H 
0 ! | Identifier (GFI) ! i 
Cc {---------------- + ee ee ee 
ae? G2, Logical Channel Number (LCN) 
T ! i 

eT uoz ACen Type identi feral? 


Figure 4/AX.25 
DTE and DCE clear confirmation packet format 


6.3 Data and interrupt packets 
6.3.1 DTE and DCE data packets 


Figure 5/AX.25 illustrates the format of the 
DTE and DCE data packets. 


Bit Position 
5 4 


ogical Channel 


! General Format {ob 
H Group Number 


1 ! Identifier (GFI) 
oD 0 2 


! 
! 
{0} ! ! 
Cc Pewee wenn neem enn enene = cece cre ee! 
T 2 Logical Channel Number (LCN) ! 
EO fewwrn nner rrerr cern sere ba blades wommanenn] 
T 3! P(R) iM! P(S) !0 
em ! 
A User Data 
R i 
Where: D is the Delivery confirmation bit 


M is the More data bit 
Q is the data Qualifier bit 


Figure 5/AX.25. DTE and DCE data packet format 


6.3.1.1 Qualifier (Q) bit 


Bit 8 of octet 1 is the qualifier bit (Q 
bit). Q bit operation is described in section 


6.3.1.2 


Bit 7 of octet 1 is the delivery confirmation 


bit (D bit). D bit operation is described in 
section 4.4.1.4. 


Delivery confirmation_(D) bit 


668% 1e3: Packet receive sequence number 


Bits 8, 7, and 6 of octet 3 are used for 
indicatin the packet receive sequence number 
P(R). PCR) is binary coded with bit 6 being the 
low order bit. 


6.34154 


Bit 5 in octet 3 is used for the More data 
mark (M bit); 0 for no more data, 1 for more data, 


More data bit 


62901459 Packet send sequence number 


Bits 4, 3, and 2 of octet 3 are used for 
indicating the packet send sequence number P(S). 
P(S) is binary coded, with bit 2 being the low 
order bit. 
6.3.1.6 User data field 


Octets following the third octet contain user 
data. The user data field must contain an 
integral number of octets. 


6.3.2 DTE and DCE interrupt packets 


Figure 6/AX.25 illustrates the format of the 
DTE and DCE interrupt packets. 


Bit Position 
5 


! General Format ! Logical Channel 
! Identifier (GFI) ! Group Number 
! 0 0 0 ! 


Logical Channel Number (LCN) ! 


Packet Type Identifier 
0) 10 0 0 1 


HrHWao 
NS 


Interrupt User Data . 


www www www wee we mew eee weer ete emerson eese 


wo 
ee 


Figure 6/AX.25. 
DTE and DCE interrupt packet format 


6.3.2.1 


Octet 4 contains user data. 


Interrupt user data field 


6.3.3 DTE and DCE Interrupt _confirmation 
packets = = 


Figure 7/AX.25 illustrates the format of the 
DTE and DCE interrupt confirmation packets. 


Bit Position 
5, 4 3 


Ss enee ite OOK Ie aay ey ess 2.40 
! General Format | Logical Channel ! 
1 ! Identifier (GFI) ! Group Number ' 
Oy ca, ie i 
(es Jame ee mmm mm wees ners eo ee ewe me ew ew ew) 
Te die | Logical Channel Number (LCN) ! 
E | eae nee n nner cern nee nnn wanna s eee e nnn! 
T ! Packet Type Identifier 
3! (0) 10 0) 1 st, 


Figure 7/AX.25 
DTE and DCE interrupt confirmation packet format 


6.4 Datagram_and datagram service signal packets 


Datagrams are not implemented in AX.25. 


625.60 DTE and DCE receive ready (RR) packets 


Figure 10/AX.25 shows the format of the DTE 
and DCE receive ready (RR) packets. 


8 7 6 Bit Position 33° Oe 
aos - == 6 Care Sct °C aaa alas aioe 
! General Format ! Logical Channel ! 
1 ! Identifier (GFI) ! Group Number ! 
! ON ON NM J 4 0 ! 


Q ! 
Cv iteeeee ee eee SAP ieee ana vast 
: 2! Logical Channel Number (LCN) 

| 
T ! ! PacketO Typ@ Id@ntifier i 


30! P(R) 


Pigure 10/AX.25 
DTE and RR packet format 


Packet receive sequence number 


Bits 8, 7, and 6 of octet 3 are used for 
pt peRe the packet receive sequence number 


P(R). P(R) is binary coded, with bit 6 being the 

low order bit. 

63 Sid DTE and DCE receive not ready (RNR) 
packets = - - - 


Figure 11/AX.25 illustrates the format of the 
DTE and DCE RNR packets. 


Bit Position 
5 4 


1 ! General Format ! Logical Channel 
! Identifier (GFI) ! Group Number 


! 
! 
0 ! 0 0 0 1 ! ! 
fos Pemew meme mmerewcnnsene ee ee ee wm ew ow ft 
T 2 i Logical Channel Number (LCN) ! 
E Vem c www eee wn wnt me were n nner eeee! 
T ! ! Packet Type Identifier ! 
3! P(R) !0 0 10 1 
Figure 11/AX.25 
DTE and DCE RNR packet formats 
6452.1 Packet receive sequence number 


Bits 8, 7, and 6 of octet 3 are used for 
indicatin the packet receive sequence number 
P(R). P(R) is binary coded, with bit 6 being the 
low order bit. 


6.5.3 Reset request and reset indication 
packets re 


Figure 12/AX.25 illustrates the format of the 
reset request and reset indication packets. 


Bit Position 
4 


8 7 6 2 1 

! General Format . ! Logical Channel ! 

1! Identifier (CFI) ! Group Number ! 

0 0 0 0 1! (LCGN) i 
6 el - =e ee ee es ew oe | 
T 2 tyy_ Logical Channel Number (LCN) __ ! 
T 1 Packet Type Identifier ! 
3} o oOo oO 1 1 0 1 1 
4! Resetting Cause ! 
{sedoceesdocicesec cole eS rr Ts | 

5! Diagnostic Code ! 


Figure 12/AX.25 
Reset request and reset indication packet format 


Resetting cause field 


Octet 4 is the resetting cause field, which 
contains the reason for the reset. 


In reset request packets, the resetting cause 
field should be set by the DTE to one of the 
following values: 


bit: 87654321 
valuel: 00900000 
value2: 1X xX XXX XK XK 


where X may be either 0 or 1 


_The DCE will prevent values other than those 
specified above in the resetting cause field from 
reaching the other end of the call by considering 


the reset request as an error and following the 
procedure described in Annex Gc. 


The coding of the resetting cause field in 
reels 
i 


the reset indication packets is given in 
11/AX.25 (Table 11/AxX.25 is at the end of 
paper ). 

6.5.3.2 Diagnostic code 


Octet 5is the diagnostic code which contains 
additional information on the reason for the 
reset. 


In a reset indication acket if the 
resetting cause field indicates "DTE originated”, 
the diagnostic code is poet unchanged from the 
resetting DTE. If the D requesting a reset has 
not provided a diagnostic code in its reset 
re uest packet, then the bits of the dia nostra 
co8e in the resulting reset indication packet wil 
all be zero. 


indication packet results from a 
: ; Rar ress the value of the 
diagnostic code will be that specified in the 
restart request packet, or all zeros in the case 
where there is no diagnostic code has been 
specified in restart request packet. 


When a reset 
restart request 


When, the resetting cause field does not 
indicate "DTE originated’, the diagnostic code in 
a reset indication packet is network generated. 
Annex E lists the codings for network generated 
diagnostics. The bits of the diagnostic code are 
all set to zero when no specified additional 
information for the reset is supplied. 


The contents of the diagnostic code field do 
not alter the meaning of the cause field. A DTE 
is not required to undertake any action on the 
contents of the diagnostic code field. 
Unspecified code combinations in the diagnostic 
code field shall not cause the DTE to refuse the 
cause field. 


6.5.4 DTE and DCE reset confirmation packets 


Figure 13/AX.25 shows the format of the DTE 
and DCE reset confirmation packets. 


BitPosition 
8 7 5 4 2 1 
! General Format ! Logical Channel ! 
Grou ' up Nunber ! 
0 ! Tdaptifjer ( (ORI) 1 ‘d Ch GN) : 
C Jecencceccecewenenene wh ee eee 
T 2 ! Logical Channel Number (LCN) ' 
EB a da al ll a ll la lee eel | 
T ! Packet Type Identifier ! 
3! 0 0 Lear ek ob 
Figure 13/AX.25 
DTE and DCE reset confirmation packets 
6.6.1 


Restart request and restart indication 
Packets 


Figure 14/AX.25 illustrates the format of the 
restart request and restart indication packets. 


Bit Position 
5 4 3 


MiB lini art Op. a Penk cae eines 2 1s. 

! General Format l ! 

1! Identifier (GFI) ! ! 

0 ; 0 0 0 1! 0 0 0 0 : 
Cc seesaw eeawanmeneeceeeeew &@ 2 © © © © & @& & 

T 2! 0 0 0 0 0 0 O 0 ! 

gE fem mmw mmm mem mmm nnn eee e ne ene mee eneececsn! 

TE ! Packet Type Identifier f 

a ae cee ak ae 

! Restarting Cause 

5! Diagnostic Code ! 


Figure 14/AX.25 
Restart request and restart indication 
packet format 


6.6.1.1 


Octet 41is the restarting cause field, which 
contains the reason for the restart. 


Restarting cause field 


3.34 


In restart request packets the restarti 
ause field should be set by the DTE to one of t 


ollowing values: 


n 
he 


bitt 87654321 
valuel: 00000000 
value2: 1XXXXXXX 
where X may be either 0 or 1 


The DCE will prevent values other than those 
specified above in the restarting cause field from 
reaching the other end of the Call By considering 
the restart request as an error and following the 
procedure described in Annex C. 


The coding of the restarting cause field in 
the restart indication packets is given in Table 
12/AX.25. 


a a ae a a ~- 8-7-6-5-4-3-F-1-— 
! Local procedure error 100000001 T 
! Network congestion 100000011 ! 
, Network operational 11. ..... 1Oo00OO1LI! 


Table 12/AX.25 
Coding of the restarting cause field 
in restart indication packets 


6.6.1.2 Diagnostic code 


Octet 5 is the diagnostic code which contains 
additional information on the reason for the 
restart. 


The diagnostic code is passed to the 
Serpe) DTEs as the diagnostic code of a 
clear indication packet for virtual calls. 


The coding in a restart indication packet is 
given in Annex E. The bits of the diagnostic code 
are all set to zero when no specified additional 
information for the restart is supplied. 


The contents of the diagnostic code field do 
not alter the meaning of the cause field. A DTE 
is not required to undertake any action on the 
contents of the diagnostic code field. 
Unspecified code combinations in the diagnostic 
code field shall not cause the DTE to refuse the 
cause field. 


6.6.2 


DTE and DCE restart confirmation packets 


Bit Position 
8 #7 6 5 4 3 2 1 


! General Format | 


! 

o 4 1 0 0 0 0°! 
c er a a a 
T2' 0 0 0 0 02. 
T ! Packet Type Identifier ! 
31 1 ! 


Figure 15/AX.25 
DTE and DCE restart confirmation packet format 


6.7 Diagnostic packet 


Figure 16/AX.25 shows the format of the 
diagnostic packet. 


8 7 6 Bft Position3 2 1 


Peewee neem esas ewes seen es cmemecesoooeseses 


! General Format 


| 
1! Identifier (GFI) ! 0 0 0 0° $! 
0 ! 0 0 0 1 ! ! 
Cc !--------------- wre-- - ee ee eee! 
a 2 ! 0 0 0 0 0 0 0 0 ! 
T ! Packet Type Identifier ! 
2 ee re ee ee ae 
! Diagnostic Code | 
5! Diagnostic Explanation (see Note 1) ! 

Note 1: The figure drawn assumes an integral 


number of octets in the diagnostic 
explanation 


Figure 16/AX.25 Diagnostic packet format 


eres Diagnostic code field 


Octet 4 is the diagnostic code and contains 
information on the error condition that caused the 
transmission of the diagnostic packet. The coding 
of the diagnostic field is given in Annex E. 


6.7.2 Diagnostic explanation field 


When the diagnostic packet is issued as a 
result of the reception of an errogneous packet 
from the DTE (see Table C-1/AX.25), this field 
contains the first three octets of header 
information from the erroneous DTE packet. If the 
packet contains less than 3 octets, this field 
contains whatever bits were received. 


When the diagnostic packet is issued as a 
result of a DCE time-out (s Table D-1/AX.25), 
the diagnostic explanation field contains 2 octets 
coded as follows: 


bits 8, 7, 6, and 5 of the first octet 
contain the general format identifier for the 
interface; 


bits 4 to 1 of the first octet and bits 8 to 

1 of the second octet are all zero for the 

expiration of time-out T10 and give the 

number of the logical channel on which the 

ee ou occured for expiration of time-out 
or Tl 


6.8.2 set-up and clearing packets for t h e 
fasteseFactlity an ast select 
—— — acceptance facility — 


Call request and incoming call packets 


6.8.2.1 


Figure 18/AX.25 illustrates the format of 
call request and the "Past call packets used in 
conjunction with the as select facility 
described in section 7.2. 


The description in section 6.2.1 applies 
here, except that the length of the call user data 
field has a maximum length of 128 octets, and 
should contain an integral number of octets. 


Bit Position 
5 4 3 


ee! ee: ee, 2 i 
1 ! General Format ! Logical Channel ! 
! Identifier (GFI) ! Group Number ! 
te) ro 1 0 ! (LCGN) 1 
Cc | -------------------- - = - 5 - - - - -! 
T 2 Logical Channel Number (LCN) ! 
E | anna nnn nnn nn enn nnn nnn ne nnn n nnn ne 
T ! Packet Type Identifier 
1 Calling DTE | Called DTE 
4 | Address Length __! Address Length  ! 
V DTE Addresses 
A! (see Note 1) 
Begg Ripe era be 
a 
0 0! Facility Length , 
V 
A! Facilities 
R 
REL NE 
vi Call User Data 
A ; (see Notes 2 and 3) 
R! 


Note 1. The figure is drawn assuming the total 
amount of address information is not an 
integral number of octets. Each address 
sub-field is potentially of variable 
length, any padding necessary is added at 
the end, and will consist of zeros. 


Note 2. Bits 8 and 7 of the first octet of the 
call user data ee ma have particluar 
significance (see 6.2.13, 


Note 3. Maximum length of the call user data 
field is 128 octets. 


Figure 18/AX.25 
Call request and incoming call packet format 
for the fast select facility 


Call accepted and call connected 


-packetS 


Figure 19/AX.25 illustrates the format of 
call accepted and call connected packets used in 
conjunction with the fast se fect facility 
described in section 7.2.4. 


Bit Position 
5 4 


8 7 6 2 iB 
! General Format | Logical Channel ! 
1 ! Identifier (GFI) ! Group Number ! 
Q gh OO Teh ads (LCGN) ! 
T 2 ! Logical Channel Number (LCN) { 
E | meee ce nn ee ee ee ee eee ee eee eon 
T ! Packet Type Identifier ! 
5 oy ey | sien gee Ba Gabe dts. Past 
| Calling DTE | Called DTE i 
4 ' Address, Length ! Address Length ! 
(eee Be ed Be Re ORS ea” Fe 8 eS ! 
V DTE Addresses 
A! (see Note 1) 
R ee ww ee wmennnn 
| 0 0 oO 0 
: 0 0! Facility Length ! 
es ! 
A! Facilities 
R 


Call User Data 
(See Notes 2 and 3) 


Note 1. The figure is drawn assuming the total 
amount of address information is not an 
integral number of octets. Each address 
sub-field is potentially of variable 
length, any padding necessary is added at 
the end, and will consist of zeros. 


Note 2. Bits 8 and 7 of the first octet of the 
call user data field a ody? have particluar 
significance (see 6.8 


Note 3. Maximum length of the call user data 
field is 128 octets. 


Figure 19/AK.25 
Call accepted and’ call connected packer format 
or the fast select facilitp 


The description in section 6.2.2 applies 
here. In addition, a call user data Fad may be 
present. If a call user data field is present, it 
can contain up to a maximum of 128 octets, and 
must contain an integral number of octets. 


If a call user data field is present the use 
and format of this field are determined by bits 8 
and 7 of the first octet of this field in 
accordance with the following: 


If bits 8 and_7 are 00, a portion of the call 
user data field is used for protocol 
identification in accordance with other 
Recommendations (such as AX.29 


If bits 8 and 7 are set to 01, portion of 
the call user data field may be used for 
protocol identification in accordance with 
specifications of networks. 


If bits 8 and 7 are 10, a portion of the call 
user data field may ‘be used for protocol 
identification iain accordance with 
specifications of international user bodies. 


If bits 8 and 7 are set to 11, no constraints 
are placed on the use by the DTE of the 
remainder of the call user data field. 


Users are cautioned that if bits 8 and 7 have 
a value other than 11, a protocol may be 
identified that is implemented within the network. 


When a virtual call is established between 
two packet mode DTEs, the network does not act on 
any part of the call user data field. 


3.35 


6.8.2.3 Clear request and clear indication 


packe ts 


Figure 20/AX.25 illustrates the format of 
clear request and clear indication packets used in 
conjunction with the fast select facility and fast 
epee re kei facility described in sections 

an 5. 


Bit Position 
8 7 6 5 4 3.42 1 
! General Format ! Logical Channel ! 
1! ar ea (cE) ! Group Number 
! Oo 0 | (LCGN) 


yao 


! 
! 
Sheela te erie vet we! 
! 
! 


Logical Channel Number (LCN) 


eeweeeeonoe wwe wee me we wwe eee we eee eecese 


Packet Type Identifier 


d 


bo 


3 ie 0 0 0 1 0.60600 11 } 
44 Clearing Cause i 
5 | Diagnostic Code ‘ 
i Calling DTE | Called DTE 
eclonddrecss Lencth..-.W1-Adduass-Length-.-! 
Vv DTE Addresses 
A! (see Note i ! 
Re | °¢ SW iiesseayooooaas-sa-S m- 
! 0 0 0 0 H 
0 0 ! Facility Length A 
V 
A! Facilities ! 
R 
| ! 
eee n enw n enn e enn enn nnn enn ene e wen nee; 
! 
Call User Data 
ee focblte8 (See Note 2) 000 : 


Note 1. The figure is drawn assuming the total 
amount of address information is not an 
integral number of octets. Each address 
sub-field is potentially of variable 
oe ay Pees necessary is added at 
the end, will consist of zeros. 


Note 2. Maximum length of the call user data 
field is 128 octets. 


Figure 20/AX.25 
Clear request and clear indication packet format 
for the fast select facility and clear indication 
packet format to the calling DTE for the called 
called line address modified notification facility 


The descriptions of the clearing cause field 
and the diagnostic code field in section 6.2.3 


cee Ee In additiion, the following fields 
may follow the diagnostic code field (the use of 
the diagnostic field itself is mandatory). 


6.8.2.3.1 Address length field 

This field is coded with all zeros. 
6.8.2.3.2 Address field 

This field is not present. 
6.8.2.3.3 Facility length field 

This field is coded with all zeros. 
6.8.2.3.4 Facility field 


This field is not present. 


6.8.2.3.5 Clear user data field 


Following the facility field, a clear user 
data field may be present, and if present, it may 
be up to a maximum of 128 octets. The clear user 
data field is required to contain an integral 
number of octets. 


6.8.4 Clear indication packet ‘ror ‘alled line 
address moditiéed notitication tacility 


Figure 20/AX.25 illustrates the format of 
clear indication packet used in conjunction with 
the called line address modified notification 
facility described in section 7.2.10. 


The espe the in section 6.8.2.3 applies 
here, except e notes attached to sections 
6.8.2.3.1 and 6.8.2.3.3 and all of sections 
6.882 63.2 5 6.82. = 4, and 6.8.2.3.5. 


Address field 


The addess field is present only when the 
call is redirected and then cleared by the network 
or by the alternate DTE without the transmission 
of the call accepted packet. It consists of the 
alternate DTE address. 


The coding of the address field is described 
in section 6.2.1.3. 


Facility field 


The facility field is present on¥ when the 
call is redirected and then cleared by the network 
or by the alternate DTE without the transmission 
of the call accepted packet. 


The coding of the facility field is defined 
in section 7. 


3.36 


! 

! 

wee e EDOU DCE WLOnDTE Wed Econ OTE ba DCE ew 8 65 4321! 

' 

! Call set-up and clearing i ! 

! Incoming call ! Call request !oo0o0o01l011! 

! Call connected ! Call accepted 'oo0o0o01111! 

! Clear indication Clear request ‘00010011! 

! DCE clear DTE clear 'o00010111! 

confirmation confirmation ! ! 

{ 

! Data and interrupt ! ! 

! DCE data ! DTE data ! x x 0! 

! DCE interrupt ! DTE interrupt 'o00100011! 

! DCE interrupt ! DTE interrupt ! 1 1! 

| ! confirmation ! ! 

! ! 

! Flow control and reset ! ! 

! DCE RR ! DTE RR 'xxxd900001! 

! DCE RNR ! DTE RNR 'xxxd00101! 

! Reset indication ! Reset request 1ooo1l1l011! 

! DCE reset | DTE reset 'oo0o011111! 

i confirmation confirmation ! ! 

! ! 

! Restart ! ! 

! Restart indication ! Restart request f'11iirliirloi1ilt! 

! DCE restart ! DTE restart !111i1i1i1i1215! 

confirmation ! confirmation ! ! 

! ! 

! Diagnostic ! ! 

! Diagnostic 11110001! 
Note an x bit may be either a 0 or 1 


Table 8/AX.25. 


! Bits 
'!87654321 


on enact ecsncnecesnnwecnoenasss|o—--- Saencc -----! 


! DTE originated ! 


! DTE originated (b) Pk RX xXx! 
‘Number busy 100000001! 
| Out of order !'00001001! 
! Remote procedure error (o0o00100d01! 


! Reverse charging een i 000 F100 24 


not subscribed 


i} 
! Incompatible destination 100100001! 
| Fast select acceptance !o00101001! 
! not subscribed ! ! 
! Destination absent !oo11i0do0ol 
| Le ee ee Ss ee 
! Invalid facility request !oo000o00g0011! 
! Access barred !oo0o0o1l011! 
!_Local procedure error foo0o01loddll ! 
oe Ge Io eee eae See eae ees eae 
! Network congestion 1!oo0o0og0o0101! 
! Not obtainable 1oo0o0olliodl! 
{ RPOA out-of-order (a) £2000 0/10/10 1! 
Where 
(a) May be received only if the corresponding 
optional user facility is used. 
(b) When bit 8 is set to 1, the bits 
represented by Xs are those included by 
the remote DTE in the clearing or 


restarting cause field of the clear or 
restart request packet. 


(d) Used for amateur to public data network 
internetworking only. 


Table 9/AX.25 


Coding of clearing cause field 
in clear indication packet 


Packet type identifier encodings 


: Bits ! 
Mathes sete. L-11t----~-,------ 876543211! 
! DTE originated !'oo00a000000! 
Lente on tolnated (4) 072 Fae hae 
! Remote procedure error !oo0o0o0o0o11 ! 
| Incompatible destination 'oo0ooagol1ldagododl! 
! Local procedure error {!o0o0o0ogo1d0l1! 
Network congestion ‘00000111! 

Where 

(d) When bit 8 is set to 1, the bits 


3.37 


represented by Xs are those indicated by 
the remote DTE in the resetting cause 
field of the reset request packet. 


Table 11/AX.25 


Coding of resetting cause field 
in reset indication packet 


